fix(security): bump sharp to 0.35.4 with lazy-load bridge for Node <20.9 - #426

sharp <=0.35.4-rc.0 inherits high-severity libvips/libheif advisories
(CVE-2026-33327/33328/35590/35591 and GHSA-g89c-p67h-r497 /
GHSA-2jg2-4ch7-h545). The fix ships in sharp 0.35.4, which is a semver
major and requires Node >=20.9.0.

- Bump sharp ^0.34.5 -> ^0.35.4 (refreshes the bundled libvips/libheif).
- Raise engines.node >=18 -> >=22 to match what CI, the Docker image, and
  the recommended setup already run, and to satisfy sharp's floor.
- README: update the "Node version >= 18.0" notes to >= 22.0.

No application code changes: the only sharp call site
(src/lib/utils.ts `sharp(buffer).png({ quality }).toBuffer()`) is
unchanged across 0.34 -> 0.35.

Verified on Node 22: npm audit clears the sharp advisory; lint,
typecheck, and the full test suite pass; and an end-to-end image smoke
test (a >1MB PNG through maybeCompressBase64) compresses correctly with
the new libvips.

BREAKING: drops support for Node 18/19 for consumers of the npm package.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

sharp 0.35.x's native binding fails to load on Node < 20.9. Since sharp
was a top-level import pulled in at boot via the tool chain, a straight
bump crashed the whole server on startup for those runtimes (~1% of
users), not just the screenshot tools.

- Load sharp lazily inside maybeCompressBase64 (only for images > 1 MB),
  wrapped in try/catch: on Node < 20.9 the server boots and every tool
  works; oversized screenshots simply return uncompressed.
- Replace the buggy string-compare Node guard with a numeric check that
  warns (does not throw) on Node < 20.9, nudging an upgrade to Node 22.
- Soften engines to >=20.9.0 (sharp's real floor) for this bridge; a
  follow-up will drop the lazy-load and require Node >= 22 once telemetry
  shows the <20.9 tail has drained.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

…ersion

Override process.versions.node before constructing the server so a single
run exercises the wrapped (<22) and unchanged (>=22) registration paths,
regardless of host Node. Addresses CodeRabbit review.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

…eview)

Address Ruturaj's review:
- Revert oninitialized.ts to the original Node <18 throw guard (unchanged).
- Replace the server.tool monkey-patch with the MCP server `instructions`
  field: instructions = nodeUpgradeNotice() || undefined. Simpler, one
  place; a temporary bridge to be removed with the lazy-load in ~2 weeks.
- Drop the now-unused withNodeUpgradeNotice helper.
- Tests: notice now asserted via client.getInstructions(); remove the
  obsolete oninitialized boundary test.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>